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Sir: 

This Appeal Brief is filed pursuant to the "Notice of Appeal to the Board of 
Patent Appeals and Interferences" mailed May 27, 2004. 

Real Party In Interest 

The real party in interest is assignee International Business Machines, Inc., 
Armonk, New York. 

Related Appeals and Interferences 

Appellants are aware of no appeals or interferences that would be affected by 
the present appeal. 



Appellants appeal the final rejection of Claims 1-7 and 19-36, which as of the 
filing date of this Brief remain under consideration. The attached Appendix A 
presents the claims at issue as finally rejected in the Final Official Action of March 1, 
2004 (the Final Action). 
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Status of Amendments 

There have been no amendments filed subsequent to the Final Official Action. 
The attached Appendix A presents the claims as amended by the Amendment of 
November 25, 2003. 

Summary of the Invention 

The invention generally relates to terminal emulation for legacy host systems 
where a synchronous communication model can be used. For example, the terminal 
emulation may be provided by establishing a first connection between a client 
application and a server application. The server application can provide updated host 
screen information to the client application in response to requests from the client 
application by establishing a second connection between a monitor application and 
the server application. Notification of the availability of updated host screen 
information is received via the second connection at the monitor application and a 
request for updated host screen information is transmitted over the first connection in 
response to receiving the notification. The requested updated host screen information 
is received at the client application and displayed utilizing the client application. 

By utilizing the second connection to the client, the server may notify the 
client of the availability of host screen information and, thereby, prompt the client to 
request the host screen information using the first, synchronous, connection. Because 
client application requests the updated host screen information in response to the 
notification from the server, the need for the user to manually request updated host 
screen information may be reduced. 

For example, in one embodiment, the monitoring application which monitors 
the second connection for notifications may be relatively small notification code or an 
applet that is embedded in a web page description (HTML) provided to the client. 
When executed, the notification code establishes a notification connection to the 
server. When the notification code receives notification of the availability of updated 
host screen information, the notification code signals the client application and 
terminates. See, for example, Application, pages 2-3. 
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Issues 

Are Claims 1-7 and 19-36 properly rejected under 35 U.S.C. § 103(a) as 
unpatentable over United States Patent No. 5,940,075 to Mutschler III et al. 
(hereinafter "Mutschler") in view of United States Patent No. 5,950,866 to 
Nakabayashi et al. (hereinafter " Nakabayashi")?. 

Grouping of Claims 

Group I: Claims 1-7 and 19-36 stand or fall together. 

Argument 

L Introduction 

The Group I Claims (Claims 1-7 and 19-36) stand rejected under 35 U.S.C. § 
103(a) over Mutschler in view of Nakabayashi. A determination under § 103 that an 
invention would have been obvious to someone of ordinary skill in the art is a 
conclusion of law based on fact. Panduit Corp, v. Dennison Mfg. Co., 810 F.2d 1593, 
1 U.S.P.Q.2d 1593 (Fed. Cir. 1987), cert, denied, 107 S.Ct. 2187. After the involved 
facts are determined, the decision maker must then make the legal determination of 
whether the claimed invention as a whole would have been obvious to a person 
having ordinary skill in the art at the time the invention was made. See Panduit, 810 
F.2d at 1596. The United States Patent and Trademark Office (USPTO) has the initial 
burden under § 103 to establish a prima facie case of obviousness. In re Fine, 837 
F.2d 1071, 5 U.S.P.Q.2d 1596, 1598 (Fed. Cir. 1988). 

To establish a prima facie case of obviousness, the prior art reference or 
references when combined must teach or suggest all the recitations of the claims, and 
there must be some suggestion or motivation, either in the references themselves or in 
the knowledge generally available to one of ordinary skill in the art, to modify the 
reference or to combine reference teachings. See M.P.E.P. § 2143. The mere fact that 
references can be combined or modified does not render the resultant combination 
obvious unless the prior art also suggests the desirability of the combination. See 
M.P.E.P. § 2 143.01 (citing In re Mills , 916 F.2d 680, 16 U.S.P.Q.2d 1430 (Fed. Cir. 
1990)). As emphasized by the Court of Appeals for the Federal Circuit, to support 
combining references, evidence of a suggestion, teaching, or motivation to combine 
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must be clear and particular, and this requirement for clear and particular evidence is 

not met by broad and conclusory statements about the teachings of references. In re 

Dembiczak, 50 U.S.P.Q.2d 1614, 1617 (Fed. Cir. 1999). In another decision, the 

Court of Appeals for the Federal Circuit has stated that, to support combining or 

modifying references, there must be particular evidence from the prior art as to the 

reason the skilled artisan, with no knowledge of the claimed invention, would have 

selected these components for combination in the manner claimed. In re Kotzab, 55 

U.S.P.Q.2d 1313, 1317 (Fed. Cir. 2000). 

Furthermore, as stated by the Federal Circuit with regard to the selection and 

combination of references: 

This factual question of motivation is material to patentability, and 
could not be resolved on subjective belief and unknown authority. 
It is improper, in determining whether a person of ordinary skill 
would have been led to this combination of references, simply to 
"[use] that which the inventor taught against its teacher." W.L. 
Gore v. Garlock, Inc. , 721 F.2d 1540, 1553, 220 USPQ 303, 312- 
13 (Fed. Cir. 1983). Thus the Board must not only assure that the 
requisite findings are made, based on evidence of record, but must 
also explain the reasoning by which the findings are deemed to 
support the agency's conclusion.... 

In re Sang Su Lee, 277 F.3d 1338, 1343 (Fed. Cir. 2002). 

The patentability of the pending claims is discussed further below. 

IL The Group I Claims Are Patentable Over the Cited References 

As briefly discussed above, Claims 1-7 and 19-36 stand rejected over 

Mutschler in view of Nakabayashi. Appellants respectfully submit that even if 

Mutschler and Nakabayashi were combined, the combination would not disclose or 

suggest all the recitations of the claims as required under Section 103. For example, 

the combination of Mutschler and Nakabayashi would not disclose or suggest 

establishing a first connection between the client 
application and a server application, wherein the server application 
provides updated legacy host screen information to the client 
application in response to requests from the client application 
using an HTTP request-response communications model, wherein 
the updated legacy host screen information is based on 
asynchronously generated information formatted for a character 
terminal of a host legacy system as part of terminal emulation 
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provided between the client application and the host legacy 
system; 

establishing a second connection between a monitor 
application and the server application; 

receiving a notification of the availability of updated 
legacy host screen information via the second connection at the 
monitor application using the HTTP request-response 
communications model; 

requesting the updated legacy host screen information 
over the first connection using HTTP request-response 
communications model responsive to receiving the notification; 

receiving the requested updated legacy host screen 
information at the client application; and displaying the received 
updated host screen information utilizing the client application. 

Claim 1 (independent Claims 19, 23, 30 and 34 include similar recitations). 

As demonstrated by the above emphasized recitations of independent Claim 1, 

a combination of Mutschler and Nakabayashi would not disclose or suggest the 

various claimed operations applied to updated legacy host screen information 

based on asynchronously generated information . In particular, as understood by 

Appellants, Mutschler relates to the form of information from a legacy host system 

displayed on a client. In other words, Mutschler discusses how data is presented on 

the screen of a client and does not address how asynchronously generated information 

is communicated to the client. For example, Mutschler makes clear that the central 

focus of the invention discussed therein is the form of how the data is presented 

rather than how information is communicated as demonstrated by the following 

passage from the "Background" of Mutschler: 

In order to "Web-enable" such a legacy application, i.e. allow it to 
work within the World Wide Web internet or intranet environment, 
it is necessary that: 1) the host application continue to be unaware 
that an agency is intervening in the display of its Forms and 2) 
these Forms need to have a "look and feel" similar to the PC 
version in order that development and training costs be minimized. 

The current state of the art for displaying Forms in the World Wide 
Web is the Hypertext Markup Language (HTML). This language 
is an instance of SGML (Standard Generalized Markup Language). 
HTML has the concept of the FORM, which is a means of 
displaying GUI controls for user interaction. When the user 
submits the HTML Form, the contents of these controls are 
gathered by the Web browser and sent as part of a Universal 
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Resource Locator (URL) sent to the Web server in the form of 
control name/control value pairs. 

The HTML FORM construct was originally considered for 
implementation of PowerClient product Forms in the web 
environment and considerable effort was expended in an effort to 
make it work. However, it as ultimately found that there were 
numerous shortcomings of this approach, foremost of which is the 
inability to simultaneously specify the caption for a control and the 
name of the host data element with which it is associated. This 
limitation made it impossible to use the HTML FORM construct to 
support PowerClient product legacy forms in the web environment. 
Moreover, while the set of available components included most of 
the PowerClient product's GUI Control set, there were still some 
which either were not supported or were of limited functionality 
vis-a-vis the PowerClient product set. Additionally, there was no 
way to control where on the Form the control was positioned. 
HTML Version 2.0 added the concept of FRAMEs, which gives 
some control over positioning. These were evaluated for 
PowerClient product's environment and found insufficient to 
control locations on the PowerClient product Form. 

U.S. Patent No. 5,940,075; Column 2, line 62 - Column 3, line 32. 

As demonstrated by the above-cited passage of the "Background" from Mutschler, the 

focus therein is how the information is displayed and not how asynchronous 

information is communicated. 

Moreover, as understood by Appellants, no part of Mutschler discusses how 

asynchronously generated updated legacy host screen information is provided from 

the host to the client. For example, in discussing the operation of the systems therein, 

Mutschler states that: 

The SCL language is used by the PowerClient product to control 
the display of Forms in the PC environment. Since this language 
completely characterizes a legacy Form for the purposes of display 
in the normal PC environment, including the legacy host 
application data field with which each GUI element is associated, a 
decision was made to use it as the means by which the Form is 
displayed in a Web browser. SCL Text is embedded into an 
HTML page for display in a Web browser environment, and 
the data entered by the user is returned to the legacy 
application. 

US. Patent No. 5,940,075; Column 4, line 45 - line 55 {emphasis added). 
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As demonstrated by the above emphasized portion of Mutschler, Mutschler appears to 
take as a given that once the information is initially generated by the legacy host 
system, it is not updated. Therefore, as understood by Appellants, Mutschler does 
not disclose or suggest the communication of updated legacy host screen information 
(based on asynchronously generated information). 

As understood by Appellants, Nakabayashi also does not disclose or suggest 
the recitations shown above to be missing from Mutschler. Nakabayashi relates to 
the management of updated web pages, not to terminal emulation. In particular, 
Nakabayashi relates to a system for providing updated web pages (including 
hypertext) to a client by monitoring updates to those web pages and then providing 
the web pages to the client, for example, in response to a specific request by the 
client. Summary of Nakabayashi. For example, Nakabayashi relates to the 
management of hypertext: 

As discussed previously, the access management 
unit reads the hypertext data from the database 410 via the 
data management unit and utilizes the function of the 
browser to display the data on the screen of the monitor 76 
via the user I/F unit 200. The user can sequentially look at 
the respective pages according to the links off line, in the 
same manner as that carried out on line. In the example of 
FIG. 35(a), the access management unit first displays the 
home page and then jumps to the linked pages A, B, and C, 
and further to the subsequent linked pages. A link to a non- 
accessed Web server is not rewritten but remains 
unchanged, so that the user can look at the data on line. 
This structure enables the user to read the contents of data 
without being specifically conscious of the position of the 
data. See Nakabayashi, column 44, lines 1 - 44. 
[Emphasis added.] 

As shown by the above emphasized portions of the cited passage, Nakabayashi 
discusses the management of hypertext data which is associated with Web pages, not 
updated legacy host screen information j s based on asynchronously generated 
information formatted for a character te rminal of a host legacy system as part of 
terminal emulation provided between th e client application and the host legacy 
system as recited in the claims. In particular, as understood by Appellants, the Web 
pages monitored by the server in Nakabayashi are made up of HTML code, not 
information "formatted for a character terminal display" as recited in the amended 
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independent claims. As further evidence, Figure 34 of Nakabayashi shows a segment 
of HTML code which is commonly referred to as hypertext data. Accprdingly, 
Nakabayashi also does not disclose or suggest the recitations of the independent 
claims shown to be missing from Mutschler. Therefore, even if Mutschler and 
Nakabayashi were combined, the combination would not disclose or suggest all of the 
recitations of the claims as required under section 103 as outlined above. 

Furthermore, there is no clear and particular evidence of a motivation or 
suggestion to combine the cited references as required under § 103. In particular, 
Mutschler relates to displaying legacy host data as a form on a Webpage whereas 
Nakabayashi does not even mention legacy host systems or providing terminal 
emulation for those systems. Accordingly, there is no clear and particular evidence 
of a motivation or suggestion to combine these references as they appear to solve 
completely different problems. 

Mutschler also appears to use the type of persistent TCP/IP socket connection 
discussed in relation to another cited reference (i.e., the Butts reference discussed in 
Appellant's response dated November 25, 2003), which does not disclose an http 
response-request communications model. In particular, Mutschler states that "the 
network connection 13 may typically comprise a TCP/IP or any other proprietary 
protocol. A understood by Appellants, persistent TCP/IP socket connections actually 
avoid the asynchronous communications problems discussed above in reference to 
the http communications discussed in Nakabayashi. As understood by Appellants, a 
persistent TCP/IP socket connection is meant to avoid closing a connection such that 
new connections need not be established for further communications. In other words, 
use of persistent TCP/IP socket connections is a way to avoid the overhead of using 
http. Therefore, the system in Mutschler would not need the communications 
approach used in Nakabayashi. 

Furthermore, the Official Action has not cited any clear and particular 
evidence of why one of ordinary skill in the art would have been motivated to 
combine these particular references. To the contrary, it appears that the Official 
Action simply states that Mutschler and Nakabayashi are analogous or similar to one 
another so that one of ordinary skill in the art would have "readily recognized" the 
desirability of the combination. The Official Action also states that one of ordinary 
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skill would have recognized the "desirability of modifying the system disclosed by 
Mutschler by employing the features shown by Nakabayashi in order to monitor 
updates to shared information in a network system without receiving overlapping 
updated data" citing col. 1, lines 41-55 of Nakabayashi. Respectfully, as understood 
by Appellants, Nakabayashi already appears to address the problem of "overlapping 
data" (as demonstrated by the cited passage). Therefore, Appellants submit that the 
cited basis for the combination is insufficient as Nakabayashi already appears to 
address the problem. Accordingly, there is no clear and particular evidence for a 
combination of Mutschler and Nakabayashi as required under section 103. 
Respectfully, this is the type of conclusory reasoning which is generally forbidden by 
the case law and sections of the MPEP cited above. 

The dependent claims are patentable over Mutschler and Nakabayashi for at 
least these the reasons described above. Accordingly, Appellants respectfully request 
the reversal of all rejections and the allowance of all claims. 

II. Conclusion 

In light of the above discussion, Appellant submits that the pending claims are 
patentable over the cited references and, therefore, requests reversal of the rejections of 
Claims 1-7 and 19-36. 

ResppdttuUy submitted, 

^_^^obert IsT Crouse 
/"Registration No. 44,635 

Myers Bigel Sibley & Sajovec, P.A. 
P. O. Box 37428 
Raleigh, North Carolina 27627 
Telephone: (919) 854-1400 
Facsimile: (919) 854-1401 
Customer No. 20792 
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Appendix A 
Claims as Rejected in the 
Final Official Action of August 20, 2003 in Application Serial No.: 09/394,536 

Filed: September 10, 1999 

1. (Previously presented) A method of providing updated legacy host 
screen information to a client application as terminal emulation between a legacy host 
system and the client application the client application utilizing a request-response 
communications model, the method comprising: 

establishing a first connection between the client application and a server 
application, wherein the server application provides updated legacy host screen 
information to the client application in response to requests from the client application 
using an HTTP request-response communications model, wherein the updated legacy 
host screen information is based on asynchronously generated information formatted 
for a character terminal of a host legacy system as part of terminal emulation provided 
between the client application and the host legacy system; 

establishing a second connection between a monitor application and the server 
application; 

receiving a notification of the availability of updated legacy host screen 
information via the second connection at the monitor application using the HTTP 
request-response communications model; 

requesting the updated legacy host screen information over the first connection 
using HTTP request-response communications model responsive to receiving the 
notification; 

receiving the requested updated legacy host screen information at the client 
application; and 

displaying the received updated host screen information utilizing the client 
application. 

2. (Original) The method of Claim 1, wherein the client application 
comprises a web browser and wherein the monitoring application comprises 
notification code. 



3. (Previously presented) The method of Claim 2, wherein the 
notification code is provided with updated legacy host screen information, the method 
further comprising the steps of: 

extracting the notification code from the host screen information; and 
executing the notification code. 

4. (Previously presented) The method of Claim 2, wherein the updated 
legacy host screen information comprises a Markup Language. 

5. (Previously presented) The method of Claim 1, wherein the updated 
legacy host screen information comprises terminal emulation information. 

6. (Original) The method of Claim 1, wherein the first and second 
connections are conducted via a single communications link. 

7. (Previously presented) The method of Claim 1, wherein the server 
application provides updated legacy host screen information to a second client 
application in response to requests from the second client application, the method 
further comprising: 

identifying the client application that requested the updated legacy host screen 
information. 

Claims 8-18 (Canceled). 

19. (Previously presented) A system of providing updated legacy host 
screen information to a client application as terminal emulation between a legacy host 
system and the client application, the client application utilizing a request-response 
communications model, the system comprising: 

means for establishing a first connection between the client application and a 
server application, wherein the server application provides updated legacy host screen 
information to the client application in response to requests from the client application 
using an HTTP request-response communications model, wherein the updated legacy 
host screen information is based on asynchronously generated information formatted 



for a character terminal of a legacy host system as part of terminal emulation provided 
between the client application and the host legacy system; 

means for establishing a second connection between a monitoring application 
and the server application; 

means for receiving updated legacy host screen information from the legacy 
host system; 

means for transmitting a notification of the availability of updated legacy host 
screen information to the monitoring application over the second connection using the 
HTTP request-response communications model responsive to receiving the updated 
legacy host screen information; 

means for receiving a request for the updated legacy host screen information 
from the client application over the first connection using the HTTP request-response 
communications model; and 

means for transmitting the received updated legacy host screen information to 
the client application over the first connection in response to receiving the request for 
the updated legacy host screen information from the client application. 

20. (Original) The system of Claim 19, wherein the client application 
comprises a web browser and wherein the monitoring application comprises an 
notification code. 

21. (Previously presented) The system of Claim 20, wherein the means for 
transmitting the received updated legacy host screen information further comprises 
means for incorporating the notification code in the updated legacy host screen 
information transmitted to the client application. 

22. (Previously presented) The system of Claim 19, wherein the server 
application provides updated legacy host screen information to a second client 
application in response to requests from the second client application, the system 
comprising: 

means for identifying the client application that requested the updated legacy 
host screen information. 



23. (Previously presented) A computer program product that provides 
updated legacy host screen information to a client application as terminal emulation 
between a legacy host system and the client application, the client application 
utilizing a request-response communications model, the computer program product 
comprising: 

a computer-readable storage medium having computer-readable program code 
means embodied in said medium, said computer-readable program code means 
comprising: 

computer readable program code means for establishing a first connection 
between the client application and a server application, wherein the server application 
provides updated legacy host screen information to the client application in response 
to requests from the client application using an HTTP request-response 
communications model, wherein the updated legacy host screen information is based 
on asynchronously generated information formatted for a character terminal of a 
legacy host system as part of terminal emulation provided between the client 
application and the host legacy system; 

computer readable program code means for establishing a second connection 
between a monitor application and the server application; 

computer readable program code means for receiving a notification of the 
availability of updated legacy host screen information via the second connection at the 
monitor application using the HTTP request-response communications model; 

computer readable program code means for requesting the updated legacy host 
screen information over the first connection using the HTTP request-response 
communications model responsive to receiving the notification; 

computer readable program code means for receiving the requested updated 
legacy host screen information at the client application; and 

computer readable program code means for displaying the received updated 
legacy host screen information utilizing the client application. 

24. (Original) The computer program product of Claim 23, wherein the 
client application comprises a web browser and wherein the monitoring application 
comprises an notification code. 



25. (Previously presented) The computer program product of Claim 24, 
wherein the notification code is provided with updated legacy host screen 
information, the computer program product further comprising: 

computer readable program code means for extracting the notification code 
from the host screen information; and 

computer readable program code means for executing the notification code. 

26. (Previously presented) The computer program product of Claim 24, 
wherein the updated legacy host screen information comprises a Markup Language. 

27. (Previously presented) The computer program product of Claim 23, 
wherein the updated legacy host screen information comprises terminal emulation 
information. 

28. (Original) The computer program product of Claim 23, wherein the first 
and second connections are conducted via a single communications link 

29. (Original) The computer program product of Claim 23, wherein the 
server application provides updated legacy host screen information to a second client 
application in response to requests from the second client application, the computer 
program product further comprising: 

computer readable program code means for identifying the client application 
that requested the updated legacy host screen information. 

30. (Previously presented) A computer program product of providing 
updated legacy host screen information to a client application as terminal emulation 
between a legacy host system and the client application, the client application 
utilizing a request-response communications model, the computer program product 
comprising: 

a computer-readable storage medium having computer-readable program code 
means embodied in said medium, said computer-readable program code means 
comprising: 

computer readable program code means for establishing a first connection 
between the client application and a server application, wherein the server application 



provides updated legacy host screen information to the client application in response 
to requests from the client application using an HTTP request-response 
communications model, wherein the updated legacy host screen information is based 
on asynchronously generated information formatted for a character terminal display of 
a host legacy system as part of terminal emulation provided between the client 
application and the host legacy system; 

computer readable program code means for establishing a second connection 
between a monitoring application and the server application; 

computer readable program code means for receiving updated legacy host 
screen information from a host system; 

computer readable program code means for transmitting a notification of the 
availability of updated legacy host screen information to the monitoring application 
over the second connection using the HTTP request-response communications model 
responsive to receiving the updated legacy host screen information; 

computer readable program code means for receiving a request for the updated 
legacy host screen information from the client application over the first connection 
using the HTTP request-response communications model; and 

computer readable program code means for transmitting the received updated 
legacy host screen information to the client application over the first connection in 
response to receiving the request for the updated legacy host screen information from 
the client application. 

31. (Original) The computer program product of Claim 30, wherein the 
client application comprises a web browser and wherein the monitoring application 
comprises an notification code. 

32. (Previously presented) The computer program product of Claim 31, 
wherein the computer readable program code means for transmitting the received 
updated legacy host screen information further comprises: 

computer readable program code means for incorporating the notification code 
in the updated legacy host screen information transmitted to the client application. 

33. (Previously presented) The computer program product of Claim 30, 
wherein the server application provides updated legacy host screen information to a 



second client application in response to requests from the second client application, 
the computer program product comprising: 

computer readable program code means for identifying the client application 
that requested the updated legacy host screen information. 

34. (Previously presented) A system for displaying updated legacy host 
screen information utilizing a web browser as part of terminal emulation provided 
between the client application and the web browser, comprising: 

a host server application; 

a browser application configured to communicate with the host server 
application using an HTTP request-response communications model; 

a first connection configured to provide communication between the host 
server application and the browser application using the HTTP request-response 
communications model; 

a notification application operably associated with the browser application that 
notifies the browser application to request updated legacy host screen information 
from the host server application for display by the browser application using the 
HTTP request-response communications model, wherein the updated legacy host 
screen information is based on asynchronously generated information formatted for a 
character terminal display of a host legacy system as part of terminal emulation 
provided between the client application and the host legacy system; and 

a second connection, established by the notification application, configured to 
provide communication between the host server application and the notification 
application using the HTTP request-response communications modeL 

35. (Original) A system according to Claim 24, wherein the first and 
second connections comprise sockets. 

36. (Original) A system according to claim 34 wherein the notification 
application is embedded in a web page provided to the browser application by the host 
server application. 



